Support ambiguous time #3786
Support ambiguous time #3786
Conversation
Signed-off-by: Breezewish <breezewish@pingcap.com>
breezewish
added
priority/critical
|
@BusyJay @solotzg @DorianZheng This is an important bug fix required by our new clients. PTAL, thanks! |
breezewish
added
priority/high
| .and_then(|t| t.checked_add_signed(Duration::nanoseconds(i64::from(nanos)))) | ||
| .and_then(|datetime| tz.from_local_datetime(&datetime).earliest()) |
There was a problem hiding this comment.
Because MySQL choses earliest when there is ambiguous time.
For example, in America/Los_Angeles time zone: After Sunday, 06 November, 2011 01:59:59 AM: Clocks were moved backward to become Sunday, 06 November, 2011 01:00:00 AM. When giving 2011-11-06 01:59:59, it can be interpreted to the following two:
-
The time before transition: 2011-11-06 01:59:59 -7 (timestamp: 1320569999)
-
The time after transition: 2011-11-06 01:59:59 -8 (timestamp: 1320573599)
In MySQL:
mysql> SET time_zone = 'America/Los_Angeles';
Query OK, 0 rows affected (0.03 sec)
mysql> select unix_timestamp('2011-11-06 01:59:59');
+---------------------------------------+
| unix_timestamp('2011-11-06 01:59:59') |
+---------------------------------------+
| 1320569999 |
+---------------------------------------+
1 row in set (0.01 sec)
mysql> select unix_timestamp('2011-11-06 02:00:00');
+---------------------------------------+
| unix_timestamp('2011-11-06 02:00:00') |
+---------------------------------------+
| 1320573600 |
+---------------------------------------+
1 row in set (0.00 sec)
There was a problem hiding this comment.
So earliest is equal to single when the conversion is unique?
There was a problem hiding this comment.
|
/run-integration-compatibility-test |
|
Please cherry-pick this to the release-2.0 and release-2.1. |
|
@shenli Got |
Signed-off-by: Breezewish <breezewish@pingcap.com>
Signed-off-by: Breezewish <breezewish@pingcap.com>
Signed-off-by: Breezewish breezewish@pingcap.com
What have you changed? (mandatory)
Supports parsing date time which is ambiguous due to DST shifting back.
This PR is a workaround that uses some low level chrono API to bypass chronotope/chrono-tz#23. Once chronotope/chrono-tz#23 is fixed, we should switch back using public and high level APIs.
Resolve #3721
What are the type of the changes? (mandatory)
How has this PR been tested? (mandatory)
Unit test.
Does this PR affect documentation (docs/docs-cn) update? (mandatory)
No
Does this PR affect tidb-ansible update? (mandatory)
No